很抱歉，你的云可能在接下来10小时停运！
什么？要停10个小时？！
在企业计算领域――无论实际的数字运算在公司自家的服务器上进行还是在别人的服务器上运行，都要几乎时刻不停地处理工作。无论是定期停运还是非定期停运，哪怕停运几分钟都会是大问题。停运几个小时？提都甭提。
那么，我们又该如何评论“甲骨文云企业托管和交付政策”（Oracle Cloud Enterprise Hosting and Delivery Policies）网站上的这个帖子，说该公司的“云服务”每个月可能会遇到大约10个小时的定期维护？对重要的服务来说，10个小时实在太长了，简直难以想象。
因而这份文件备受关注。相关内容如下：
甲骨文为变更预留了一段特定的维护时期，变更可能需要云服务在维护期间停运。甲骨文竭力确保在定期维护期间落实了变更管理程序，同时考虑到了低流量时期和地域方面的要求。定期维护时期通常是每月一次，定于周五，大概从数据中心本地时间20:00开始，持续10个小时左右。
有一个相关链接论述了例外情况，但这个链接无法公开访问。《财富》杂志周五联系上甲骨文，请对方就此事发表评论，必要时会更新这篇报道。
一些服务在周末夜晚下线可能无关紧要，也可能大有影响，这取决于涉及的是那些服务、客户从事什么业务。
对于一些公司的某些应用软件来说，为周末或夜间开设六七个小时的定期维护窗口并不罕见。比如说，有一些任务可以定于维护前后的时段来加以处理。工资单系统可以在周末下线，以更新税表，用户也不会大为光火。华盛顿特区的一名IT顾问表示，但是，对于一家访客量很大的全球零售商而言，要是支付系统在周末下线是不可接受的。这名顾问为甲骨文的政府客户服务，由于这种关系，他不愿透露姓名。
这方面不是很清楚的一点是，“云服务”是不是肯定指甲骨文数据库服务，还是指可能不大关键，但还是很重要的其他应用服务。如果云服务是指数据库，这是个特别重大的问题。
这名顾问对这份文件感到很困惑，他认为这不是个错误，要么就是缺少了什么重要的东西。
他在电子邮件中写道：“这似乎太离谱了。我无法相信，我每月要为两个区域的甲骨文企业RDBMS花2000美元，每月却要停运10个小时――外加任何计划外时间。”RDBMS是指关系数据库管理系统，在大多数人看来它不止是个数据库。
甲骨文云主管表示，马逊云并没有为企业做好准备。
亚马逊网络服务（AWS）有自己的关系数据库服务或RDS，每周定期维护30分钟，这里有概述（http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBMaintenance.html）。 RDS用户告诉《财富》杂志，预定的这些更新时段很容易避免停运时间。
10年前，AWS一开始在初创公司的软件开发人员当中颇受青睐，后来重视赢得大公司的单子，而甲骨文在大公司拥有巨大势力。去年，AWS推出了一款迁移工具，以便将数据库从客户的服务器迁移到AWS。客户随后可以选择继续在甲骨文或微软SQL Server上运行数据库，也可以（如亚马逊希望的那样）将该工作负载迁移到AWS替代方案，比如亚马逊的Aurora数据库。
亚马逊率先采用了这种模式：为租給厌烦维护自家数据中心的客户使用的数据存储和网络资源构建庞大的数据中心。这种“公共云”模式对于像IBM和甲骨文这些传统软硬件公司的生存构成了威胁，因为这些老牌公司靠向大量的客户数据中心销售昂贵的软硬件来赚钱。
现在由于更多的客户租用AWS、微软或谷歌的数据中心，这种模式发生了变化，甲骨文加大了云计算领域的力度，以便在这个新领域更有竞争力。它手中的一张王牌是，甲骨文数据库在许多大公司运行，而数据库又是很难搬迁的系统，哪怕有迁移工具。
技术咨询公司Dovel Technologies主管研究和开发的高级副总裁肯尼思·怀特（Kenneth White）说：“甲骨文确实开发了一款优秀的产品，但是从企业的角度来看，这么长的[维护窗口]肯定不受待见。”
确实，甲骨文在云爱好者当中存在一个感知问题，这些云爱好者认为，这家公司仍没有“搞懂”云。这个长达10个小时的维护窗口可能只会加深这种感知。
云头条编译
距离发布会只剩5天，戳阅读原文，可查看七牛直播云发布会详情！